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Abstract — This paper presents deductive program- 
ming for scheduling scenario generation. Modeling for 
solution is achieved through program transformations. 
First, declarative model for scheduling problem do- 
main is introduced. After that model is interpreted 
as scheduling domain language and as predicate tran- 
sition Petri net. Generated reachability tree presents 
search space with solutions. At the end results are 
discussed and analyzed. 

I. Introduction 

Two general directions are under consideration 
in this paper First, deductive programming will 
be used as methodology for solution to scheduling 
problem. The second direction is experience that 
improves protocol synthesis due to synergism 
between scheduling and deductive programming. 
Declarative programming is concerned about what 
is to be done rather then how is it implemented. 
Declarative model is interpreted and transformed to 
executable model. 

In this paper word model is frequently used. 
Model can present requirements, program, agent 
or behavior in pure mathematical way or through 
the program code. Nowadays, there are numerous 
formal methods, specification languages, model 
checking and theorem proving tools. Putting 
together different methods, tools and languages is 
obtained through model transformation, component 
composition software composition or similar 
methods. 

This paper use different models, each of them is 
suitable for its particular purpose. Declaration part 
comes from language specialized for scheduling 
problem definition. Executable part is found in 
high level Petri net. Together, by means of model 
transformation solution to the problem is found. 
This paper is structured as follows: before model 
translation between declarative and executable 
models two solutions are presented, one by means 
of Predicate Petri net (Pr/T) in Section |ll] and 
the other by Planning Domain Definition Language 



(PDDL) in Section Unl respectively. 

Working example is introduced in textual form 

in Section |Vl In Section |IV] unification between 

the Pr/T and PDDL model yielding translation 

between the models is introduced. Section |Vl] 

introduces metamodel as generalization of model 

transformations. 

Experience from model translation and scheduling 

synthesis is used for scenario synthesis in Section 

Ivml 

Solution to scheduling problem as extended finite 
state machine (eFSM) and LTU — T message 



sequence diagram (MSC) is in Section IVIII 
Final Sections of the paper bring related work 
(Section |X]) with some reflection regarding 
synthesis process (in Section HXl ) as well as briefly 
recapitulate literate programming methodology and 
noweb tool. 

At the end in Section |Xl] is conclusion with further 
research directions. 

II. Predicate Petri net 

In this Section Predicate Petri net {Pr/T) so- 
lution is described. Textual problem from working 
example (SectionlV]) is defined by {Pr/T) constructs 
and analyzed. In following text working example 
will be referenced as 4wsltob-problem shorter 
as 4wsltob. 

From the modeling point of view two models can 
be identified: 

- mathematical model: Pr/T is introduced as 6- 
tuple 

- program code that is input to PrT tool for analysis 
Predicate-Transition Petri net definition is taken 
from Q. The tool implementing Pr/T [8] has been 
derived following the same formal definition. Pr/T 
is 6-tuple structure or mathematical Pr/T model 
(5, T, F, K, W, Mo) such that: 

S is the set of places, 

T is the set of transitions, S" n T = 0, 



F is the set of arcs, F C (5 x T) U (T x S), 

K is the capacity function, K £ {S ^ N^), 

W is the arc weight function, W £ {F ^ {N \ 

{0})), 

Mq is initial marking (in initial state) Mq G A4 

where Ai is the set of markings (states), M = 

{M G (5 ^ iV) I Vs e 5 M{s) < K{s)}. 

Pt/T tool used in this paper is PROD fS\, [P]. 

Analysis is performed by means of reachability tree 

generation. 

Figure \T\ represents programming model Pr/T for 

4wsltob-problem example: 

- places (represented as circles) are sides of the 
"bridge", representing Safe and Unsafe part of the 
bridge. 

- transitions (represented as boxes) are actions or 
events (toSafe and toUnsafe) denoting "crossings": 
es is event when (sj, Sj) are crossing from Unsafe 
to Safe, and ejj is {sk) crossing from Safe to 
Unsafe, respectively 

- < mQ,7ni,m2,m3 > are markings 



Unsafe 



< mo,..., ma > 




< mo,..., 1713 



e-u = (sfc) 

Fig. 1. Predicate Transition net for 4wsltob problem 
(Pr/T) 

There is no direct support for time in Pr/T as well 
as in PROD program. They are fulfilled afterwords 
(subsection lll-AI) . by means of special program filter. 
More detailed description of Pr/T in PROD syn- 
tax shows that Pr/T is also declarative 4wsltob 
problem description. In fact, graph structure from 
Fig{T] has program representation or program model 
that consists of: 

(1) definitions: tokens in Pr/T are of type inte- 
gers, they are used to "carry" information about 
elapsed time, 

(2) places: Safe and Unsafe 

(3) transitions toUnsafe and toSafe 

Definitions are: 

♦define si 10 
♦define s2 20 
♦define s3 25 
♦define torch 1 



Unsafe place has initial markings describing "all 
soldiers are in Unsafe place": 

♦place Unsafe \ 
mk 
(<. sO .>+<. si .> + 
<.s2.>+<.s3.>+< .torch. >) 

Each transition {toSafe and toUnsafe) implements 
previously mentioned events es and ejj, in is input 
place and out is output place, respectively: 

♦trans toSafe 
in {Unsafe: 

< .X. >+< .y . >+< .torch. >; } 
out {Safe: 

< .X. >+< .y . >+< .torch. >; } 



♦trans toUnsafe 

in {Safe: <. x .>+<. torch .>; } 

out {Unsafe: <. x .>+<. torch .>; } 

Goal is here expressed as computed tree logic (CTL) 
formula. Formula is used after reachability tree is 
generated. For that purpose separate program ana- 
lyzer (probe) is used. 

Safe place will eventually have all tokens (or all 
soldier will be at safe side of the bridge): 
♦define goal 
Event uallyOnSomeBr an ch 
(safe == 
<.l.>+<.5.>+<.10.>+<.20.>+<.25.>) 

> All paths (branches in CTL PROD terminology) 
with solutions are present. In order to decrease 
reachability tree timing constraints are separately 
calculated. 

A. Path filter: time analysis 

Path filter selects only paths where goal-condition 
timing constraint holds: 



^elapsed — / ^ ''i[(^i) S tr. 



where: 

ti(ei) - event timing, 

m - path length 

One of such paths is presented in the Section I VII I 

As conclusion to this Section, experience from 

Pr/T analysis can be applied to scheduling scenario 

generation: 

1) Pr/T has mathematical or formal model 
expressed as 6-tuple with program 
representation-model in C-like syntax 
denoted as Adprxipd = Awsltob) 

2) Pr/T is also declarative model because it 
describes structure, analysis through reach- 
abiUty analysis establish Pr/T as exe- 



cutable model.Executable model is denoted as 
MpRooipd = 4:Wsltob) , 
3) another declarative models that are established 
as a n-tuple consisting of entities, predicates, 
events/actions and similar structure can be 
transformed to Pr /T. 

III. Planning Domain Description 
Language 

PDDL (Planning Domain Definition Language) 
belongs to PDL (Problem Domain Language) |6] 
class of languages. PDDL has syntax similar to 
Lisp and describes what has to be done rather 
than how is implemented. That fact makes PDDL 
natural candidate for declarative Modeling. 
PDDL main purpose is to serve as input language 
for many planning tools. In this paper PDDL is used 
as declarative input whose syntax is more general 
and intuitive and that can hide formal method from 
the user Q. 

Declarative PDDL model describing 

4wsltob-problem is 5-tuple: 

■M.pDDL{pd = ^wsltoh) = 

{predicates, actions, 

objects, initial _state, goal_state) 

where: 

- objects: items of interest, for 4wsltob objects 
are objects={so, si, S2, s^} 

- predicates: properties of objects, can be true or 
false, (example: Is Sj in state S ?) 

- initial state(s): set of starting predicates formula 
(all Si in Unsafe) 

- goal state(s): set of goal predicates formula (all Si 
in Safe) 

- actions (operators): "crossing" the bridge ex- 
pressed through precondition and ejfect predicates 

In previous section (SecjII]) place and state are 
'words' with similar but in general case different 
meaning, because PDDL and Pr /T languages have 
different semantic. In previous section (SecjII]) Pr/T 
has two models: mathematical and programming. 
PDDL has also two models, but both are expressed 
through Lisp-^^Q syntax. PDDL can also serve as 
input to other planning and scheduling tools. 
M.pDDL{pd = Awsltoh) problem is expressed 
through PDDL constructs. Each construct is Lisp- 
Mke expression. Working example (4wsltob from 
Sec. IV]) will be used to illustrate M.pDDL{pd = 
Awsltoh) constructs. Now, we can say that PDDL 
program has the same syntax for mathematical and 
programming model. PDDL example starts with ver- 
batim list of constructs: 



(define (problem 4wsltob01) 
(:domain 4wsltob) 
(objects) 
(predicates) 
(initial_state) 
(goal_specif ication 
(actions_operators) ) ) 
Each construct will be described in more details. 

A. Objects 

Following notation from lITOl types are introduced 
for each object: 

a) So, si,S2, S3 are objects of type sold, 

b) torch is object type torch, 

c) Safe, Unsafe are objects of type place 
Objects in PDDL are not object from object oriented 
programming paradigm. In Lisp-like syntax objects 
are defined by term rewriting: 

(objects) : : == 

(:objects sO si s2 s3 - sold 
torch - torch 
Safe Unsafe - place) 

Now object constmct is PDDL executable, that 
means planning tools can execute it. Similarly 
other constructs are rewrote (or replaced) producing 
declarative specification. 

B. Predicates 

Predicates can be used within other components. 
Is token sold Si in place pj ? is expressed as: 

( :predicates 

(pi ?sold ?place) ) 

C. Initial states 

In initial state component all tokens (sq, si, S2, S3) 
are in Safe place and Unsafe place is empty. Timing 
parameters ij are set, too. Initial time is set as: 

( : init 
(= (t-elapsed) 0) 

Initial state components are coded as follows: if 
token ?x is in place Unsafe than token ?x is not 
in place Safe, yielding following initial conditions: 

(pi sO Unsafe) 

(not (pi sO Safe)) (= (ts sO) 5) 

(pi si Unsafe) 

(not (pi si Safe)) (= (ts si) 10) 

(pi s2 Unsafe) 

(not (pi s2 Safe)) (= (ts s2) 20) 

(pi s3 Unsafe) 

(not (pi s3 Safe)) (= (ts s3) 25) 

(pi torch Unsafe) ) 

Predicate (= (ts Sj) tj) initialize crossing time for 
object Si. 



D. Goal state 

Goal specification component is theorem about 
system behavior. If solution exists place Unsafe is 
empty and all tokens of type sold are in place Safe. 
Solutions are found if goal is proved: 

( : goal (and 
(pi sO Safe) 

(not (pi sO Unsafe) ) 
(pi si Safe) 

(not (pi si Unsafe) ) 
(pi s2 Safe) 

(not (pi s2 Unsafe) ) 
(pi s3 Safe) 

(not (pi s3 Unsafe) ) 
(pi torch Safe) 

Goal has timing goal condition t^iapsed < 60 ex- 
pressed as: 

( (<= t-elapsed) 60) ) ) 

E. Actions 

Action operators realize the following functional- 
ity: 

a) two objects (or tokens) are transfered from Un- 
safe to Safe, time teiapsed incremented 

b) single object (or token) is transfered from Safe 
to Unsafe, time teiapsed incremented 

c) redundant token torch is left in PDDL because 
implementation must support silent-moves (e- 
actions) 

d) parameters ? x and ? y are of type sold 

Objects are used within PDDL terminology while 
tokens are used within Pr/T terminology. Model 
transformations unifies objects and tokens, they will 
be mixed and used as synonyms. Each action consist 
of preconditions and effect. 

- Effect is es or eu event mentioned earlier in Fig. 

msecini 

- Precondition must hold in order an effect takes 
place. 

- Preconditions for toSafe action ai"e two tokens of 
type sold in place Unsafe. 

- Precondition for toUnsafe action is token of type 
sold in place Unsafe. 

1) toSafe action: 
Event es is realized with toSafe action: 

(:action toSafe :parameters (?x ?y) 
: precondition 
(and (pi ?x Unsafe) (not (pi 
(pi ?y Unsafe) (not (pi ?5 



2) toUnsafe action: 
Event eu is realized with toUnsafe action: 

: effect 
(and 

(pi ?x Safe) 

(not (pi ?x Unsafe) ) 

(pi ?y Safe) 

(not (pi ?y Unsafe) ) 

and increment elapsed time teiapsed- 

(+ (t-elapsed 

(max (ts ?x) (ts ?y) ) ) ) ) ) 

toUnsafe action is similar to toSafe action, single 
token of type sold is going to Safe place and 
token ?x is removed from Safe place and put 
into the Unsafe place. Precondition with effect is 
semantically equivalent to condition-event or 
Place-transition in Petri nets. That enables 
smooth model transition to non-colored Petri nets. 

(:action toUnsafe :parameters (?x) 
: precondition 



(and 




(pi ?x Safe) 


(not (pi ?x Unsafe) ) 


(pi torch Safe) 


(not (pi torch Unsafe 


effect 




(and 




(pi ?x Unsafe) 


(not (pi ?x Safe) ) 


(pi ?y Unsafe) 


(not (pi ?y Safe) ) 



(+ (t-elapsed (ts ?x) ) ) ) ) 
PDDL described in this paper produces the same 
results with (Ipg) planning software. Program 
is executable after minor adjustments through 
software provided by [6| project. 
Parameters (N = A, Ks = 2, Ku = 1, t„,ax = 60) 
are preserved through transformation from 
■MpRODipd = Awsltob) to M-prxipd = 4wsltob). 

IV. Programming for solution 

In this paper intention is to derive executable 
model from deductive or declarative model. Terms 
deductive and declarative are used as synonyms 
although from the formal point of view it is not the 
same. 

Intention is to define model {A4{pd = Awsltob)) 
as executable without inventing yet another spe- 
cialized Modeling or specification language. That 
opens possibilities for reasoning about the model 
properties and consequently introduces validation in 
early development phase. 

This hypothetical C program becomes deductive pro- 
gram. Deductive or declarative program must have 
(pi torch unsafe) (not (pi torch Safe^y^ii^^i^iy defined algorithm that should deduce only 
Effect should place chosen tokens in Safe place: from declarations and predicates output results. Such 



'X Safe) 
Safe) ) 



C program describes What is done rather than How 
is it done. 

The same proposition holds for M.{pd = Awsltob) 
PDDL and PrT models. We shall use shorter no- 
tation, M.{jpd) where pd is always pd = Awsltob. 
Ai{pd) is focused on What is to be done rather then 
How is it done. Natural candidates for the model 
A4{pd) translation are Prototype Verification System 
(PVS) ifTOl . term-rewriting systems and Lisp family 
of languages. Our solutions uses Lisp like languages. 
Modeling for solution effect is achieved through 
the following model transformations presented as 
commutative diagram in Figj2] Such approach veri- 
fies proof-of-concept through model transformation 
experiments. 

TRj and TR^ are program transformation routine. 
In practical solution TRj and TR^ will be realized 
through the metamodel concept: deductive will be 
interpreted through metamodel, metamodel is trans- 
lated to executive model afterwords. In this paper 
direct model translation is used. Metamodel facilities 
are introduced in Section |Vl] Each transformation 



M{pd) ^-^ VVVCi ^^ VAfp 



Fig. 2. Commutative diagram for model transformations 

between models Ai{pd) require parser, because 
model transformation is program transformation. In 
order to avoid parser development following facts 
are considered: 

1) mathematical models for PDDL is 5-tuple, in- 
troduced with lisp syntax, 

2) mathematical models for PrT is 6-tuple, ex- 
pressed as mathematical text, not as program- 
ming language 

3) PROD program is inC-like syntax and 
presents instantiation of PrT 

PROD program describing PrT is coded in Lisp like 
constructs: 

#trans toSafe 
in {Unsafe: <. x .> + <. y .> + <. torch .>; } 
out {Safe: <. x .>+<. y .>+< .torch .>; } 

becomes Lisp PROD or I PROD: 

( : trans toSaf e 

:parameters (?x ?y ?torch) 

:in (Unsafe ?x ?y ?torch) 

:out (Safe: ?x ?y ?torch) 

Note the similarity between PDDL :action 
construct and IPROD : trans construct. 



A. Unification 

There is set of mappings between PDDL and 
IPROD: 

- : init < — > initial-marking 

- : goal < — > final-marking 

- : action i — > #trans 

- : objects i — > < . tokens . > 

Translation between PDDL and IPROD is 
straightforward: the set of mappings unify PDDL and 
IPROD. 

V. Example scenario 

This example belongs to the set of "toy-problems" 
used in experiments during algorithm testing. 

A. Textual scheduling problem definition 

Working example is simple scheduling problem 
taken from [5], listed verbatim: 

Four soldiers who are heavily injured, try 
to flee to their home land. The enemy is 
chasing them and in the middle of the 
night they arrive at a bridge that spans 
a river which is the border between the 
two countries at war The bridge has been 
damaged and can only carry two soldiers 
at a time. Furthermore, several land mines 
have been placed on the bridge and a torch 
is needed to sidestep all the mines. The 
enemy is on their tail, so the soldiers know 
that they have only 60 minutes to cross 
the bridge. The soldiers only have a single 
torch and they are not equally injured. 
The following table lists the crossing times 
(one-way!) for each of the soldiers: 

- soldier 5*0 5 minutes 

- soldier 5i 10 minutes 

- soldier 52 20 minutes 

- soldier 5*3 25 minutes 

Does a schedule exist which gets all four 
soldiers to the safe side within 60 minutes? 

VI. Scheduling domain metamodel 

abstract model here - no metamodel needed 
here Scheduling domain metamodel is derived from 
PDDL model. Metamodel supports constructs from 
type theory, concurrency theory as well as process 
algebras. 

After the analysis of the text from Section 
rvl the following list of constructs are in- 
troduced: parameters, entities, predicates, events, 
traces, initial-conditions, goal-conditions, operators 
and constraints. 



In the next step each construct is described through 
Lisp -l\ke constructs: 

(def -abstract -semantic-net 
" met amet amode 1 " 
(problem-domain 4wsltob) 
(parameters construct) 
(entities construct) 
(predicates construct) 
(events construct) 
(traces construct) 
(initial-conditions construct) 
(goal-conditions construct) 
(operators construct) 
(constraints construct) ) 

Parameters are data of types integer or real: 

(1) number of soldiers n = 4 

(2) ...carry two soldiers (to safe side) 
Ks = 2 , and Kjj = 1 (to unsafe) side. 

(3) ...cross times: to = 5, ti = 10, t2 = 20, 
t3 = 25, 

(4) ...have only 60 min. to cross the bridge 

Torch is not considered here because it has not 
influence on model behavior Next models {VT>VC, 
hlVN) can include it but that is not necessary. 

(def -parameters 
(n 4 int) 
(KS 2 int) 
(KU 1 int) 
(to 5 real) 
(tl 10 real) 
(t3 20 real) 
(t4 25 real) 
(t-max 60 real) ) 

Entities are two sets: one set are variables and 
the other are values. Set A is describing dynamic 
behavior of the model: in each execution step values 
from set As are assigned to variables from S. 

1) set of soldiers: sq • • • S3 of type sold 

2) set describing sides of the bridge. They are 
introduced as places {Safe side and Unsafe side) 
of type place. 

Unknown parameter is denoted as lA or IAS. 

(entity (A (sO si s2 s3 s4)) 
(entity (AS (Safe Unsafe) ) 

Predicates answers the question: 

(1) Where is si ? 

(2) Is Si in side Safe or Unsafe 

(pred atPlace ?A) 
(pred ?A ?AS) 

There are two atomic events: 

(1) two soldiers Si and Sj are going to Safe side 

(2) single soldier Sj is going to Unsafe side 

(3) event has duration time i. 



(eS (Unsafe (?x ?y) Safe) 

(time (max (?tx ?ty) ) ) ) 

(eU (Safe ?x Unsafe) 
(time (?tx ) ) ) 

If there is solution for this problem traces should 
be of finite length r coded as finite length vector, 
such that ?e is ?eS or ?eU event of duration 
?total-time. This model has no built-in infinite 
traces. 

(Er (foreach r ?e) ?total-time) 
Initially all si are on Unsafe place. This model 
has no time counter (initial-condition (A (atUnsafe 
atUnsafe atUnsafe atUnsafe))) At the end all soldiers 
must be within 60 minutes in safe side: 

(goal -condition 

(A (atSafe atSafe atSafe atSafe) ) 
(<= total-time t-max) ) 

Operators and constraints constructs serve as 
additional model input in complex situations where 
M{pd) is profiled recursively. 

VII. Solution 

There are 16 paths from total of 824 paths where 
timing condition t^iapsed ^ 60 min holds. As an 
example one path is presented: 

PATH 33 

Node 0: transition toSafe 

X = 5 y = 10 
Node 1: transition toUnsafe 

X = 5 
Node 7: transition toSafe 

X = 25 y = 20 
Node 13: transition toUnsafe 

X = 10 
Node 20: transition toSafe 

X = 10 y = 5 
Node 21 

Node 0,1,5,13 ... are nodes from reachability 
tree. Variable x and y are crossing times, for toSafe 
transition or es event crossing time is max{x,y). 

A. Visualization: eFSM 

Figl3] visualize lfT4ll solution in the form of ex- 
tended Finite State Machine (eFSM). Next step can 
transform eFSM into the input language for analysis 
tool. Another possibility is to generate skeleton code 
in C or Java programs. 

B. MSC solution 

Message sequence charts 117] is another form 
that can visualize solution (FigjJ]). Even the 



toSafe{x = 5,y = 10) 



toUnsafe{x = 5) 



toSafe{x = 2h,y = 20) 



toUnsafe{x = 10) 



toSafe{x = 10, y = 5) 



Fig. 3. solution as real-time program (eFSM) 



more MSC can be used as source for another set 
of translations into the statecharts, SDL diagrams . . . 
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Fig. 4. solution as Message Sequence Diagram(MSC) 



VIII. Synthesis and scheduling 

How can planning and scheduling methods influ- 
ence synthesis? 

Synergy effect between scheduling and synthesis 
opens possibilities for interpreting (eFSM) in various 
ways. Each of them benefits through skeleton or 
templates for code, scripts or architecture 
definition. During requirement phase many differ- 
ent scenarios can be automatically generated. We 
found that "side-effects" or parts of scenarios- 
specifications that are less obvious but present are 
reduced. 
Decidability and computability of our approach is 



not optimal for big examples because of state ex- 
plosion problem. Heuristic scheduling algorithms are 
of little practical importance for synthesis problem. 
Different problem will in most cases have differ- 
ent declarative program. For that purpose Petri net 
reachability algorithms will be replaced with satisfi- 
ability (SAT) algorithms. 
Some interpretation of solutions are: 

a) protocol synthesis 

b) SDL process: skeleton of program SDL can be 
generated and used by designer 

c) MSC skeleton processes can be composed in 
system. Overall behavior is analyzed as early as 
in requirement phase 

d) parallel program job scheduling: an experiment 
for dynamic job allocation for parallel program 
is planned using proposed methodology 

Besides mentioned interpretations other possibilities 
are: 

a) real-time system job scheduling 

b) control software synchronization 

c) performance prediction 

d) ontology definition concept analysis 

e) system maintenance 

f) object and methods definition and optimization 
Proposed approach introduces methodology for 
identifying and minimization of states in FSM like 
models of concurrent reactive systems. 

IX. Scope and motivation 

There are various approaches for synthesis prob- 
lem, the most significant are: 

(a) the temporal logic formula describes the system. 
Synchronization part of the system is derived 
from temporal formula. This can be, roughly 
speaking, interpreted as reverse model checking. 

(b) from formal service specification to protocol 
specification. Formal description is transformed 
into protocol specification. Even the more, in 
most cases specification is executable enabling 
verification, simulation and analysis . . . 

(c) extended finite state machine is constructed from 
executable traces. Traces are sequences of mes- 
sages, signals or sequence of events. They can 
be defined by designer, in this paper intention is 
to provide traces automatically to the designer. 

Our approach introduce traces or more preciously 
event traces as declaration for desired system behav- 
ior. An event describe crossing the bridge (example 
from Section |Vl Sequence of events define trace. 
The set of all traces represents search space where 



solution should be found taking timing constraints 
into the considerations. 

In this paper traces are interpreted as Petri net 
reachability tree paths. Reachability tree paths and 
traces describe the same behavior model. 
If various models A4 have same behavior model then 
they can be transformed. Transformation is mapping 
of constructs between models, before mapping con- 
structs are unified. 

Only paths with desired property (crossing time 
limit) are solution paths. 

Another question is how to only generate traces that 
are solution i.e. to avoid state-space combinatorial 
explosion. Declarative meta-model has no knowl- 
edge about it. 

Modeling for solution has three steps: 
(i) model definition 
(ii) translation to domain specific language (in our 

case PDDL - scheduling&planning 

language). PDDL can be used as input for 

scheduling planning tools, 
(iii) translation to high level Petri net for analysis 

and solution finding. 
It is obvious fact that model-for-solution can 
start and find solution from step (ii) or step (iii) 
without the model. In complex situations, when 
system is not formally described, where constraints 
and assertions about the system are contradictory, 
unknown, unclear or unspecified such model- 
mixing proves its value. Another motivation is to 
give designer or modeler support to-play-with with 
different tools and approaches in order to achieve 
desired quality of solution. Formal approaches 
explore the benefits and experience from automatic 
deductive programming, program transformation as 
well as Uterate programming. 
Previous work were focused on synthesis as 
component composition: smaller architectural 
parts or system blocks were composed into the 
target system. Such approach has usable results 
for component based architectures like services 
definition within the intelligent networks as found 
in numerous ITU — T recommendations. Later 
on, working example problem is solved with 
high level Petri net in a way close to approach 
described in SecJIIl As a consequence, scheduling 
scenario interpreted as MSC scenario yields another 
synthesis approach. Such interpretation can produce 
MSC chart as solution or synthesize executable 
specification by means of scheduling methodology. 
Modeling for solution follows experiments towards 
synthesis of scenarios and its translation to finite 
state machine based systems Uke statecharts or 



ITU-T SDL language. This paper also try to address 
such question through reachability tree analysis of 
scheduling solver. Results and methodology from 
another research field (planning and scheduling) are 
exercised, yielding synergistic effect on protocol 
or concurrent reactive system design. Experience 
shows that scheduling problem generalization and 
synthesis issues can benefit from each other. 
In |fT9l Modeling framework suitable for 
experiments is introduced. Modeling framework 
consists of several levels, each level describes 
position in model hierarchy, from the most 
abstract level on the top to implementation level 
at the bottom. Within each level components are 
introduced (traditionally called 8CV (Elementary 
Communicating Processes) as black boxes that 
enables program, tools or even models inter working. 

X. Related work 

In |[T6l synthesis is described as message sequence 
chart (MSC) translation into the Real-time Object 
Oriented Model (ROOM). After that, designer can 
use ROOM model for simulation as well as other 
purposes. Formals description technique (MSC) de- 
scribing system architecture and behavior is inter- 
preted as executable model. MSC serves as top- 
level-model which can be analyzed, simulated and 
implemented. 

Functional specification of the problem and temporal 
logic yields state-based automaton as solution for el- 
evator problem lITSl . Satisfiability analysis generates 
synchronization part of the system. 
Synthesis of behavior models from scenarios is 
introduced in [IJ and ||2]. 

PROMELA model serves as input of spin protocol 
verifier from [5 1. Results are presented through MSC 
diagrams. 

Results from mathematical description with process 
algebra and concurrency presented in [4| are used 
for further development of metamodel described in 
Section IVll Another metamodel comes from [18|. 
Model transformation routines are developed by 
means of noweb literate programming tool. Liter- 
ate programing discipline has been introduced by 
D.E. Knuth . . . instead of imagining that our main 
task is to instruct a computer what to do, let us 
concentrate rather on explaining to human beings 
what we want a computer to do. 
There are many literate programming supporting 
tools |[T3l providing human readable files that in- 
corporate documentation and source code into the 
single file. In this paper all sections illustrating 



concepts and constructs (functional style programs) 
are produced with literate programming tool noweb 

im, mi- 

XI. Conclusion and further work 

Synergy effect between planning, scheduling and 
synthesis can improve design process. There are no 
universal approach for synthesis problem so only 
narrow problem domains are possible to solve with 
difficulties regarding NP-hard algorithms and unde- 
cidable problems. This papers describe proof-of- 
concept rather then industrial strength approach. 
Pros (+) and cons (-) can be summarized as follows: 
(+) synergism between synthesis and scheduling 
planning: all ready developed routines for schedul- 
ing have been adopted and used 
(-) state explosion: Petri net can produce unman- 
ageable reachability tree size. Reachability analy- 
sis tool support is designed for model checking. 
Some scheduling issues are unsuitable for model- 
checking technology 

(-) narrow problem domain: declarative model 
requires significant changes with small domain 
change 

(-) small scale problems: synthesized components 
are sometimes easier to handle by hand 
(-(-) proof of concept: model transformation is us- 
able programming paradigm 
(-) complex theoretical background: designer 
should have deep understanding of all models and 
translation process 

(-I-) solution for critical applications: mission criti- 
cal software can be developed in this way yielding 
stable solutions 

(-I-) open research platform: modifications and up- 
dating to new algorithms 

(-I-) interworking of different paradigms and formal 
methods 
Further work will (1) use satisfiability algorithms 
and (2) explore formal methods interworking. Syn- 
thesis method should serve as testbed for formal 
languages semantic analysis and executable speci- 
fication languages. 
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